FIG. 1 illustrates a prior art on-line commerce service architecture in which the principle manner of commerce is auctioning. According to the architecture of FIG. 1, the on-line auctioneer provides the ability for an individual to list an item for sale on the Internet 103; and, for those having interest in purchasing the listed item, the ability to submit a bid for the listed item over the Internet 103. The on-line auctioneer further resolves multiple bids for a same item and determines which bidding party is deemed to be the purchaser of the item. The application software of the on-line auctioneer that is responsible for listing the items to be sold and determining the winning bid for each listed item can be viewed as part of the on-line auctioneer's Information Science (IS) resources 109. Such IS resources are often referred to as the on-line auctioneer's “back-end” resources.
Because of the high volume of both listed items and submitted bids that is achievable through the Internet 103, the on-line auctioneer's back-end resources 109 are apt to include clusters of high performance computing systems (e.g., mainframes and/or workstations). By contrast the equipment 110 used by an end-user 101 (e.g., an individual who lists an item to be sold and/or submits bids for a listed item) is apt to be lower performance computing system (e.g., a personal computer (PC), notebook/laptop, or handheld device). The prior art mechanics of the communications that take place between the end-user 101, the end-user's equipment 110 and the on-line auctioneer's IS resources 109 are depicted in the architecture of FIG. 1.
According to the depiction of FIG. 1, the end-user makes keystrokes and mouse clicks (or the equivalent thereof) that are interpreted by an end user interface 102. In a typical approach, the end user interface 102 is a modest software routine that is downloaded to the end user's equipment 110 over the Internet 103 by the on-line auctioneer's IS resources 109 in response to the end-user 101 having made an HTTP request to the on-line auctioneer's home page. The end user interface 102 is responsible for converting the end-user's keystroke and mouse-click sequences into appropriate messages 107 that are sent over the internet 103 toward the auctioneer's application software 104.
Typically, the application software 104 can be viewed as having an application programmer's interface (API) 116 at the network interface; where, the API includes commands dedicated for communication between the end-user and the auctioneer (e.g., “Bid”, “Sell”, “Register”, etc.). As such, the messaging 107 sent by the end user interface 102 corresponds to network communications (e.g., one or more packets) that describe the end user's activity in API compatible terms. For example, the specific sequence of keystrokes and mouse clicks that correspond to the user's attempt to make a bid invokes the “Bid” command. Invocation of the Bid command (and perhaps associated information) is effectively packetized by the end-user interface 102 and sent over the Internet 103 to the auctioneer's application software 104.
The on-line auctioneer's application software 104 controls the end-user's presentation experience (as suggested by presentation manager 110. In so doing, messaging 108 describing changes to the user's presentation experience (e.g., a new web page for viewing) are sent over the Internet 103 from the auctioneer's application software 104 to the end-user's equipment 110. The messaging 108 may be implemented as one or more packets that are formatted to describe the presentation changes as API compatible information. The end-user interface 102 (which typically includes a graphical user interface (GUI)) presents visual content 106 to the end user so as to make the presentation change(s) visually apparent. As discussed in more detail below, emails 109 may also be exchanged between the end-user and the auctioneer's application software (noting that functions such as an email server 111 may be deemed part of the auctioneer's application software 104 for purposes of convenience).
FIGS. 2a through 2c demonstrate some prior art process flows that can be executed by the auctioneer's application software. FIG. 2a shows a registration process that can be viewed as being executed by the “add user” component 112 of the application software, FIG. 2b shows a bidding process that can be viewed as being executed by the “bidding” component 113 of the application software; and, FIG. 2c shows a listing or selling process that can be viewed as being executed by the “listing” component of the application software. Each of these components 112, 113, 114 are drawn as being coupled to some form of database resources 115.
According to the registration process of FIG. 2a, the standard course of procedure is to have an end user send a ‘filled out’ registration form 201. If the form has an error 202, presentation change messaging 203 is sent to the end user that notifies the end user that the registration attempt was unsuccessful and should be retried. If the registration form is filled out properly an inquiry 204 is made to see if the particular end user has already been “email registered”.
Email registered means that a file exists within the archives of the auctioneer for the end-user which includes the user's email address. If the user is not email registered (i.e., if no email is recorded for the end user) an unconfirmed user file that includes the user's email address is created 205 (note that, in one embodiment, the user's email address is found in the properly filled out form). If the user is email registered an inquiry 206 is made to see if the end-user is “email confirmed”. Email confirmed means that a code that is specific to the end-user is successfully received by the auctioneer via email from the end user.
If the user is also email confirmed, presentation change messaging 208 is sent to the end-user indicating that the registration process has previously been successfully. If the user is either not email registered or not email confirmed the auctioneer sends 207 an email to the end user that asks the end user to send his/her code via email (in one embodiment, the password is first included in the filled out form and the email exchange is performed to confirm the code). Upon receipt of the return email from the end-user 209, an inquiry 211 is made to see if the code is correct. If not, another email is sent to the end-user requesting the code 207. If so, a confirmed user file is created 212.
Referring to FIG. 2b, if a bid is received from an end user and is correctly referenced to the end-user's code 213, the bid is entered in a database 214 and an email is sent to the end-user that confirms that the bid has been entered in the auctioneer's system 215. Referring to FIG. 2c, if a sales listing is received from an end user and is correctly referenced to the end-user's code 216, the sales listing is entered in a database 217 and an email is sent to the end-user that confirms that the bid has been entered in the auctioneer's system 218.